E-commerce transaction facilitation system and method

ABSTRACT

A method of operating a computer to facilitate a commercial transaction involving a plurality of negotiable trading parameters. The method includes the following steps resulting from the execution of a computer program: 
         accepting in respect of a first entity ( 3 ) a desired trading profile including at least desired values or ranges of multiple of said trading parameters and information for establishing one or more functional relationships between variations in at least a key trading parameter and other of said trading parameters; establishing one or more mathematical relationships between variations in at least the key trading parameter and the other of said trading parameters; wherein said one or more mathematical relationships can be used to determine a set of trading profiles having substantially equal expected desirability values to said desired trading profile; and    determining whether a submitted trading profile from a second entity ( 4 ) has a desirability value that equals or exceeds the desirability value of said desired trading profile using said one or more mathematical relationships.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent applicationSer. No. 11/491,271 entitled “E-Commerce Transaction FacilitationSystems and Method,” filed 21 Jul. 2006, which is a continuation of U.S.patent application Ser. No. 10/244,955 entitled “E-Commerce TransactionFacilitation System and Method”, filed 16 Sep. 2002, which is acontinuation of International Patent Application No PCT/AU01/00299,entitled “E-Commerce Transaction Facilitation System and Method”, filed16 Mar. 2001, which claims priority from Australian Provisional PatentApplication No PQ6289, entitled “E-Commerce Transaction FacilitationSystem and Method”, filed 16 Mar. 2000, the contents of which areincorporated by reference herein in its entirety.

The invention relates to the facilitation of commercial transactions,and relates particularly to the facilitation of commercial transactionsusing electronic communications networks, otherwise known as e-commercetransactions. The invention relates to the facilitation of activitiesthat occur within a real economic trading system by providing amechanism by which the structure, dynamics and business processrequirements of ‘real’ economic processes and emulated and therebycontributing to efficiently functioning markets and optimaltransactional outcomes.

Globalization of the world economy and the increasing ubiquity ofInternet usage have resulted in product markets becoming increasinglymore competitive and immediate than ever before. Despite the immenseinterest in facilitation of business-to-business (B2B) transactionsusing e-commerce, a cost-effective and easily implemented B2B solutionthat provides comprehensive e-enablement for market search,e-procurement and e-sales functions that integrate with/to enterprises'back-office software systems is not generally in use.

A model for economic interaction in the form of a computer-based systemdoes not exist that provides a comprehensive solution that enablesbusiness enterprises to use the communications infrastructure of theInternet to transact online within an economic environment/frameworkthat possesses the structural characteristics of ‘real’ economicprocesses that are essential to producing optimal transactionaloutcomes. Moreover, existing tools are particularly inadequate toaddress the complexity associated with international transactions wherethe trade amounts are often significant.

To date, Internet-based business systems that cater to facilitatingcommercial transactions between business enterprises (B2B) have beendeveloped using economic frameworks that are seriously flawed. Numerousdifferent models or configurations of so-called “digital marketplaces”have emerged in recent years. These existing models would appear to bebased on an imprecise understanding and/or use of the technology thatresults in a distortion of fundamental economic principles.

For example, the existing e-commerce models emphasize the notion ofcreating digital marketplaces. Two predominant models are the “businessportal” that provides a centralized multi-product “retail or end-user”style model; or the “industry-specific marketplace” model. Although bothpurport to create digital marketplaces, these models represent anelectronic environment in which business contacts may be establishedthat may lead to the eventual transaction of business. However, neitherof these models is capable of capturing the subtle complexity of thedynamics underlying well-functioning markets.

Until now, B2B e-commerce business systems have neglected to deal withthe subtle, distinctions that exist between the concepts of markets,industries, firms and products. The failure to properly configure theprocesses that flow from the inter-relationship between these conceptshas had the effect of creating artificial business environments ratherthan extending existing product markets.

Instead, efficient and well-functioning digital markets must beconfigured within an economic framework that enhances and extends,rather than distorts, the competitive dynamics and structuralrelationships of existing patterns of economic activity and behaviour.

The economic dimensions of commercial processes are complex and operateat many different levels. In a conventional context, the economicinter-relationships that combine to produce well functioning markets andresource-efficient business transactions arise from signals andfeedbacks between buyers and sellers that are channelled throughmultiple forms of information networks. The Internet has challenged theconventional forms of information signals and feedbacks as theinformation network is capable of consolidation within a single medium.

A consequence of the unification of information delivery within a singledynamic medium is the mistaken belief that a change in informationnetwork structure has the potential to change the principles underlyingfundamental economic behaviour and relationships. This belief, however,is not accurate. In order for an economically-based business system tofunction consistent with first best principles of efficiency, systemsmust be designed to be consistent with, and enhance, economic structuresand processes in order to deliver efficient market and transactionaloutcomes.

In order to construct an efficient commercial delivery process withinthe parameters of electronic business networks, the Applicant hasdetermined that it would be desirable for there first to be anidentification and understanding of the structural inter-relationshipsbetween prevailing economic concepts/conditions that must be presentwithin an economic system in order to generate efficiently functioningmarkets and optimal transactional outcomes. Second, it would bedesirable for the business process related transactional flows withinand between information channels within the system to be clarified.

Table 1 is a table of factors to help explain the conditions that theApplicant has determined to be desirable to embed within the structureof an efficiently functioning economic system. An optimized electronicB2B model should be capable of emulating the most critical of the subtleeconomic interactions that spontaneously occur under conventionalcircumstances. This has not yet been built into current electronic B2Bmodels because no one has adequately articulated the composition of aunifying economic framework that could provide the system infrastructurefor an electronic economic system.

The foundation of the electronic economic system developed by theApplicant is based upon an inter-related set of three parametricconditions. Each parametric condition provides an ingredient required inorder for the ‘economic process’ to function properly. The three systemparameters are the:

-   -   equilibrium condition/force    -   optimization condition/force    -   maximization condition/force

In an e-commerce applications context, each of the three parameterscorresponds to an important systemic function that transpires within theframework. In order to simplify the arguments that will follow, Table 1identifies the key relationships that will be discussed further below:TABLE 1 Parametric Dimensional Functional Application ConditionCharacteristics Attributes Purposes Equilibrium Structural Themacroeconomic Firm to market, mechanics (market) to firm to firmmicroeconomic connectivity (firm) inter- and data relationshipcommunication channels Optimization Competitive Convergence of User(strategic) dynamics demand and supply behaviour- signalsforces/tensions and feedbacks Maximization Process Internal resourceTask handling efficiency utilization and and management allocationdecision-making

In broad terms, an ‘economic system’ is the sum of a series ofinter-connected sub-system relationships. The sub-systems are thegenerators of dynamic forces that each sub-system both injects into, andextracts from, the system in order to execute a ‘core business process’.Each sub-system, in turn, is comprised of a consolidation oftask-oriented business processes that influence (feed into) thecharacteristics of the sub-system level process.

The inter-relationship among the three above-referenced systemparametric forces to be captured within an e-commerce model can besuccinctly contextualized as follows. At the system level thepredominant force is the well-functioning system's tendency towardsequilibrium (i.e., the balancing of opposing dynamic (supply and demand)forces. At the sub-system level, the predominant function is to reachoptimal demand-side or supply-side oriented transactional outcomes (theexchange function). The optimization process, in general terms, is afunction of the enterprise's business process driven tendency towardsmaximizing resource (demand-side expenditure or supply-side revenuegains) relative to the market (equilibrium) benchmark.

In a business process/transactional context, Table 2 is a table offactors that have a subtle, business process inter-relationship. TheApplicant has developed a particular configuration of the direct andindirect economic relationships between these structural factors, thatis implemented in a manner that, within the context of the medium,efficiently channels information flows to optimize the business processoutcomes that correspond to those relationships. TABLE 2 Market Focusand Functions Transaction Focus and Functions Buyer Seller Demand SupplyIndustry Firms Product market Products

From a business process perspective, the commercial process can beviewed as having two discrete stages. First is a “market-oriented”dimension. Second, this orientation subsequently shifts at a criticalpoint in the commercial process to a specific “transactional focus”. Afeature that distinguishes the two is the subset of factors whichrepresent the dominant forces that influence the discrete outcomesoccurring at the evolving stages of a commercial process.

The origin of a transaction begins with a buyer. Buyers, in economics,equate with a “demand” or the desire to satisfy a material need. Inorder to satisfy this need, the buyer conducts a vertical“drilling-down” or information gathering process that begins at ageneral level and moves to increasing degrees of specificity inidentifying:

-   -   the product it wants more precisely (for: example, a boat or a        automobile; that is, what general industry);    -   where, or the source, from which the product can be obtained        (for example, which firm supplies the product);    -   comparative product characteristics; i.e., price, quality        availability etc.

At this stage, the information gathering process is driven by, andconforms most closely with neo-classical demand theory. Within thecontext of competitive dynamics, the process explains how buyer-leddemand-side forces are the predominant influence affecting the progressof the search from a general to specific refinement process.

At the broadest level, a buyer will conduct a search within more generalparameters—at the industry level. An industry, however, is most easilydefined as a categorization, typology, or grouping of firms thatconsists of those firms that operate processes of a sufficiently similarkind and could produce products that are close substitutes. Some firmswithin an industry will produce certain products, while other firmsbelonging to the same industry may produce an entirely different rangeof products. Although there will be a “market” for all products producedby the industry, clearly, there is no such thing as a single “industrymarket”.

The forum, or institutional environment in which the buyer exercises itsdemand-side influence takes the form of what is described as a “productmarket”. However, a precise definition of what constitutes a “productmarket” is among one of the more elusive concepts in economics. In fact,there exists no single concept of exactly what is a market. Onedefinition (the Lancastrian definition) asserts that markets should bethought of as being made up of “products having similarcharacteristics”. A combination of these above definitions results in aconcept that markets are a notional forum in which products havingsimilar characteristics are exchanged.

At a particular point in the buyer's decision-making process, afundamental event in the spatial orientation of the demand-sideprocesses occur. At the moment the buyer decides upon the specific typeof product it is seeking, the decision-making process ceases to bevertical, and shifts to a horizontally oriented comparative analysisbetween like goods.

The predominant demand-side function influencing this stage of thetransaction is the comparative analysis conducted between productshaving the same or similar characteristics. If the Lancastriandefinition of what constitutes a “product market” is used, it is at thispoint the buyer truly enters the “product market”.

As a consequence of the comparative analysis among goods which are closesubstitutes, the buyer will eventually select a particular product thatmost closely conforms to its demand requirements relative to the priceit is prepared to pay for that good. In this way, the“selection-decision” is made.

The relational configuration of a buyer seeking information and productspecificity is a one (buyer) to many (sellers) (1:M) relationship.Therefore, buyer-led market activity takes the form of a buyer using themedium to identify sellers, compare the characteristics of the productsthey offer relative to the price indicated (signaled). Properly designedInternet demand-oriented mechanisms have the potential to increase thespeed and efficiency with which the buyer conducts search,identification and comparison activities. Business system applicationsthat emulate efficient “market activities” should be directed towardsenhancing the search, identification and comparison functions.

A search mechanism that links one buyer to many sellers through acentralized “portal” configuration is appropriate provided that thescope of the search is sufficiently comprehensive to identify and locatea wide enough number of suppliers and, ultimately, products to give thebuyer a good approximation of the comparative characteristics of theproducts offered.

However, existing e-commerce models utilize economic frameworks thatcreate distorted and dysfunctional markets as a result of two errors ofstructural logic.

First, centralized “portal” style models include within the market onlythose products that sellers choose to offer for sale within the system.This configuration resembles more an agency, distribution or retail salearrangement rather than an extension of existing markets. Goods areplaced in an artificial environment in a retail sale style arrangementrather than reflecting cross-comparative attributes characteristic oftrue markets.

Another structurally unsound attribute of the existing models is thatthe centralized market place which purports to facilitate sales createsa shift from vertical to horizontal spatial functions at the wrongstructural dimension. The mechanical implications of this occurrence isthat it becomes impossible to optimally integrate subsequent functionswhich occur in the business process and which are discussed below.

The selection decision described above ceases the vertical movement ofmarket-oriented activities from general to specific. It also ceases the1:M buyer to supplier relationship. The importance of this change isthat another fundamental shift occurs by implication. Rather than havinga “market” focus, the business process takes on a “transactional” focus.

The focal point for this analysis alters in that previously it was abuyer:market relationship. Now by implication of the organizationalstructures of production, the focal point is the buyer: selling firmrelationship.

In order to make a sale, the buyer must meet the seller's terms andenter the transaction process. A question now arises as to how tooptimally configure the most efficient transaction process by buildingon, or extending from, the vertical market functions described above.

Transactional outcomes can be well-explained using classical and modemtheories of the firm and neo-classical price theory. In addition, ahorizontal supply-side transactional orientation is also consistent withconcepts of supply-chain efficiency and efficient internal managementstructures.

An organizational concept that is central to both theoretical principlesis the concept of control of key supply-side functions.

One view is that firms or business enterprises exist because they areinstitutional structures that constitute an optimal mechanism fororganizing production, on the one hand, and exchange on the other. Bothfunctions involve the generation of “transaction costs”. In this regard,the firm can be seen as a form of interface between the production andexchange functions that exists because it is the structure best capableof most efficiently internalizing transaction costs.

An optimal organizational structure minimizes the transaction costs ofproduction and exchange. In this lies a very strong argument thatbusiness transactions can be most efficiently conducted where thecontrol and conduct of the transaction rests with the seller.

The mechanics of this assertion relate back to the close relationshipbetween signals and feedbacks. Firms formulate signals in response tofeedbacks. However, signals can only be seen by the market to beadjusted at an external level where the firm has made some internaladjustment as a consequence of feedbacks.

The product pricing decision is among one of the most fundamentaldecisions a firm makes. Price is a key market signal that can be quicklyadjusted in the short-run, and can be used to indicate many messagesranging from product quality to the efficiency of the firm itself.

A notable difference exists between the signal, or asking price, of aproduct: The ultimate selling price of a product is dictated by a numberof closely related factors that are determined by circumstantialconditions. For example, the negotiation of a contractual price will besubject to, among other things:

-   -   volume discounts,    -   payment risks    -   payment time    -   country risk    -   transport arrangements

In brief, price negotiations are conducted in a manner that balances therelative influence of the price-related factors in determining a finalsale price.

Present e-commerce systems do not emulate real markets. Most can beclassified as either being buyer (price-maker auction sites) or sellerdriven (fixed price-taker sites) that generate artificial or distortedmarket outcomes. In order to provide efficient and relevant e-commercetool, transaction hubs cannot be restricted to a fixed-time, lot by lotsales process. Similarly, fixed priced sales mechanisms do not allow forrapid and dynamic adjustment of price relative to short-run sellerstrategies or price influencing factors such as those described above.

In summary, the Internet is a communications network that possessesmedia and computational attributes that allow for the unification ofinformation distribution and processing functions that conventionallyoccur using numerous information distribution and processing channels.

The market-related functions of the business process are demand-side ledand involve a one to many relationship where the buyer's demands are metthrough an information gathering and analysis process that involves avertical drilling down from a general to specific level.

The Internet is capable of handling such functions through a centralizedinformation gathering, categorizing and sorting mechanism. To ensure theaccuracy of information, it is desirable to take the information soughtdirectly from the seller.

Where the buyer identifies a specific product type it wants, it stopsgathering information in a vertically flow and a spatial shift to ahorizontal product-level comparison takes place.

The selection decision is the critical point at which the buyer, byimplication, enters a, 1:1 relationship with a firm. Buyer-led,demand-side market related activities cease and supply-side forces beginto drive the business process. The process takes on a transactionalorientation rather than market orientation.

The institutional focal point for supply-side activities is the firm.The firm is an interface between markets and production that existsbecause it is the institutional structure that is most efficiently ableto internalize transaction costs associated with market-related andproduction-related activities.

In order to manage the inter-relationship between market-side andproduction-side functions, firms must control the signal/feedbackprocess. Feedbacks are used to make internal adjustments. This, in turn,allows long-run adjustment of signals. In the short-run, the seller mustcontrol the pricing and negotiation processes in order to maximizeflexibility in the pricing decision arising from strategic competitivedecisions or the negotiated adjustment to factors affecting a finalprice outcome.

Finally, horizontal control of the transaction process allows for supplychain fluidity and consistency. A horizontal distribution oftransactional information flows allows for efficient integration oftransaction outcomes across the supply-chain.

The Applicant has determined that the implications for e-commerce ofthese considerations are that ‘market-related’ functions are best suitedto take place within centralized search and consolidationconfigurations. By contrast, real product markets exist as extensions tofirms in that they are institutional structures that produce and placegoods in product markets. The nature of the supply-side transactionalaspects of the business process are made most efficient, and conformmost closely to economic theory, where the key supply-side functions arecontrolled in a decentralized format by firms themselves.

In order to provide the infrastructure for efficient market andtransactional functions to take place, tools such as dynamic negotiatingdevices and fluid and comprehensive supply-chain integration processesare required from e-commerce business software. To date, no such toolsare known to exist.

Accordingly, there currently exists a need to address one or more of thevarious shortcomings of the existing systems and methods available forfacilitating e-commerce transactions.

The Applicant has recognized that commercial transactions can beadvantageously facilitated within a systemic framework that is designedto emulate economic processes thereby providing a method by whichbusiness process activities can occur within a system structure thatcoordinates, communicates and facilitates timely and appropriateexchange of specific information to appropriate recipients, at variousstages of the transaction process, results in efficiently functioningmarkets that promote optimal transactional outcomes, that is configuredto accommodate international, intra-firm and domestic transactions whichtransactions are managed from pre-transaction through topost-transaction execution stages conforming to the transactionparameters.

In particular, the Applicant has developed an economic system thatenables an exchange/transaction process to occur within a framework thatemulates real economic processes. The invention provides the basis for asystem structure that is capable of achieving dynamic equilibrium. Theequilibrium state is derived from a structural configuration thatfacilitates a balance through the interaction and alignment of ‘near’equivalent dynamic supply (emanating from supply module) and demandforces (emanating the procurement module). The matching of supply anddemand forces is further facilitated by business process activities thatsupport the execution and management of exchange transactions byproviding mechanisms that expedite the matching process.

The structure of the system enables the matching of a firm's procurementrequirements with suppliers of product items having information aboutthose products located within markets, or supplied directly by otherfirms within the system or by firms that are not part of the system butare given access to the system for the purposes of placing productswithin it.

Preferably, the mechanism by which the matching of the first firm'sprocurement requirements with the product's offered for sale by a secondfirm is performed by a computer-based device that remains within thecontrol of the respective firms. The respective matching mechanismsrepresent the procurement and sales modular components of a singledevice performing separate, but complimentary, buy and/or sell relatedfunctions. The procurement and sales components may interact with athird search/directory component that performs ‘market-related’functions.

In particular, the Applicant has recognized that commercial transactionsare advantageously facilitated by obtaining information from one or moreof the multiple parties involved in a commercial transaction todetermine one or more possible sets of trading parameters that may beacceptable to the parties. Moreover, the Internet is a vastcommunications network which a large numbers of business enterprises canuse to conduct business transactions. In this respect, the Internet is apowerful tool of communication that consolidates within a single medium,the ability of an organization to transmit “outward” messages or signalsto attract potential partner organizations to a business transactionwhile simultaneously permitting organizations to receive and act upon“inward” responses, or feedbacks, from external organizations.

It is emphasized that the Internet is a tool that can directly enhancefirms'“exchange” related functions (i.e., interaction with markets andbuyers) but indirectly enhances “internal production and supply”functions. In a direct sense, the Internet is capable of enhancing the“price and product” signals it sends to the market (in general) andbuyers (in particular). The feedbacks from these signals can be used andinterpreted to alter or adjust:

-   -   further external signals in the form of price relative to        quality to assist in increasing and optimizing market efficiency        consistent with neoclassical price theory    -   operations of the firm to further improve process efficiency to        further reduce unnecessary transaction costs.

It is important that a firm is in an organizational position to receiveand be sensitive to feedbacks. Here, there is a long-run and short-runadjustment dimension that must be considered. Over the longer run, firmsuse feedbacks to make internal decisions and organizational adjustmentsthat can then be efficiently signaled back to the market. In theshort-run, firms can internalize feedbacks that may alter most powerfulmarket signal—the pricing decision. It is at this point price theoryplays an appropriate role in understanding business process.

In order to emulate efficient, well-functioning markets, the pricing andnegotiation decisions are preferably placed within the control of theseller. Since the price decision is a short-run decision, it is one thatcannot be easily transferred to a third part to control on behalf ofmost sellers. Accordingly, any automated price-related tool is desirablywithin the seller's direct control for rapid adjustment responsepurposes, and is both dynamic and multi-parametric.

From a supply-side perspective, and at the product market level oftransactional specificity, the supply-chain moves horizontally from afirm's externally oriented market activities into its internalorganizational and production oriented structures and functions.

In order to optimize efficiency in the form of maximizing price andquality signals to the market while simultaneously seeking to minimizetransaction costs, it is preferable that a firm should control keyfunctions of pricing signals (in the product catalogue), negotiation(transaction hub) and transaction management (post-transactionconsolidation) and supply-chain responses (back-end internal integrationinto ERP systems).

Accordingly, in a first aspect, the invention provides a method offacilitating a commercial transaction, the method including:

providing a set of trading parameters;

accepting in respect of a first entity a desired trading profileincluding desired values or ranges of multiple of said tradingparameters; and

accepting in respect of said first entity one or more further tradingprofiles including values or ranges of multiple of said tradingparameters;

establishing one or more functional relationships between variations ina key trading parameter and one or more other of said tradingparameters;

wherein each of said further trading profiles are equivalent indesirability or expected value to said desired trading profile, and saidfunctional relationship can be used to determine a set of equivalenttrading profiles having substantially desirability equal expected valuesequivalent to said desired trading profile and said further tradingprofiles.

Preferably, said first entity is a seller and said trading profilerelates to the trading parameters desired by a seller.

Preferably, a submitted trading profile accepted from a second entitycan be compared against said equivalent trading profiles of said firstentity to determine whether the submitted trading profile is more orless favourable to the first entity that said desired trading profile.

Preferably, trading profiles are generated by or on behalf of said firstand second entities with an intention to conduct a commercialtransaction, are generated at least with a view to determining marketdemand or supply for a product or service to which said tradingparameters of said trading profiles relate. Preferably, the first andsecond entities are respectively a seller and buyer, though in otherembodiments these roles may be reversed.

Preferably, said trading parameters include one or more of: price,volume, payment terms, credit terms, credit rates of interest.Preferably, said key trading parameter is price.

Preferably, when said submitted trading profile is more favourable thansaid desired trading profile, a transaction between said first andsecond entities is initiated. Preferably, the terms of said transactionare based on a transaction trading profile which has trading parametervalues which are derived from said submitted trading profile, and/or oneor said equivalent trading profiles.

Preferably, said one of said equivalent trading profiles is said desiredtrading profile, or an equivalent trading profile which is “closest” ona minimum squared distance measure or equivalent measure from saidsubmitted trading profile. In other embodiments, said transactiontrading profile is “between” said desired trading profile and saidsubmitted trading profile, in the sense that the transaction tradingprofile may represent a compromise between terms of the desired tradingprofile, and terms of the submitted trading profile.

Preferably, when said submitted trading profile is less favourable tosaid first entity than said desired trading profile, steps arepreferably performed with a view to establishing a submitted tradingprofile and a desired profile that are compatible (i.e. said submittedtrading profile being more favourable than said desired tradingprofile). This may involve a modification of the values or ranges of-aid trading parameters of said submitted trading profile and/or saiddesired trading profile. In such cases, it is preferably suggested toeither or both of said first, and second entities what changes could bemade to their respective trading entities to establish compatibletrading profiles.

In a further aspect, the invention provides a method of facilitating acommercial transaction, the method including:

providing a set of trading parameters;

accepting in respect of a first entity a desired trading profileincluding desired values or ranges of one or more of said tradingparameters; and

generating a metric representative of the desired trading profile;

wherein said metric can be used as the basis for comparing said desiredtrading profile with a proposed trading profile.

Preferably, the method further includes generating a metric representingthe expected value of the desired trading profile. Preferably, themethod further includes accepting from said at least one party multipledesired trading profiles having equal or substantially equal expectedvalues.

Preferably, in each of the equal or substantially equal desired tradingprofiles, at least the trading parameter of price is different in eachprofile. Preferably, in each of the equal or substantially equal desiredtrading profiles, changes in price are indexed against each of the othertrading parameters besides price.

Preferably, in each of the equal or substantially equal desired tradingprofiles, the sensitivity of the trading parameter of price isquantified against each of the other trading parameters. Preferably,this relationship is quantified by an approximate mathematicalexpression. This relationship may be linear or nonlinear in one or moreof the trading parameters. Preferably, the sensitivity of price againsteach of the other trading parameters is independently quantified.

Preferably, parties to the transaction at least include a buyer and aseller. In some embodiments, the parties to the transaction include aseller and multiple prospective buyers. In this case, the method mayfurther include auction-based techniques.

Advantageously, calculations are performed to determine one or more setsof trading terms which agree with the desired values/ranges of the atleast two parties.

Preferably, the prospective buyer and the prospective seller arerespectively identified by a search based on a product and/or serviceclassification code.

In another aspect, the invention provides a method of identifyingprospective partners in a commercial transaction, the method including:

providing a product and/or service classification code;

providing a database of records relating to respective businessentities, said records including information, indexed according to saidclassification code, recording at least one product or service providedby or required by said entity and at least one desired trading profilein relation to said at least one product or service;

performing, in response to supplied search information including atleast one classification code, and at least one submitted tradingprofile, a search of said database for entities having a desired tradingprofile at least compatible with said submitted trading profile.

Preferably, said classification code is organized in a hierarchicalmanner, so that search information of variable specificity orgranularity can be provided. Preferably, said classification code is, oris based on or derived from an internationally recognized product and/orservice classification code. Preferably, the classification code is, forexample, the Harmonized Tariff Code, or HTC.

Preferably, the search information optionally includes supplementaryinformation specific to business organizations, such as geographicregion, desired trading terms, credit profile etc.

Preferably, the results of the search can be ranked by one or morepredetermined criteria.

Preferably, a number of search fields can be optionally specified in thesearch information to increase the specificity of the results of thesearch.

Preferably, the search is performed by a particular user, and searchinformation preferences specific to that particular user are taken intoaccount when conducting the search.

In particular, the search and negotiation stages of the transaction mayprovide a configuration of trading parameters that set the terms of anexecutable sales contract. The configuration choices made by systemusers can result in a series of permutations and combinations ofbusiness process tasks that must be completed before the transactionwill qualify as being executed. The business process tasks must beexecuted conforming to the transaction outcome requirements.

Preferably, the contract execution process involves the satisfaction ofany one or more of transport and logistic functions, banking orfinancial functions, insurance and inspection functions, and theadjustment of production, planning and inventory functions within theselling firm.

In a further aspect the present invention provides an e-commercetransaction facilitation system including:

at least a first enterprise resource planning system operativelyconnected to a first sales module; and

at least a second enterprise resource planning system operativelyconnected to a first procurement model;

wherein one or both of the modules are each implemented by a processingunit and an associated memory unit maintaining computer program coverfor causing a method according to any one of claims 1 to 25 to becarried out.

The coordination of the execution of these functions may be conducted ina manner whereby each step in the execution process contract executionprocess must be satisfied in a stepwise manner in order to minimize useof resources and risk associated with contractual non-performance orfailure on the part of either party to the contract.

Embodiments of various aspects of the invention are advantageouslyimplemented in computer software enabled devices and systems. Further,it is highly desirable that embodiments of various aspects of theinvention are implemented with the assistance of a communicationsnetwork, such as the Internet.

In order to assist in arriving at an understanding of the invention, apreferred embodiment is illustrated in the attached drawings. However,it should be understood that the following description is illustrativeonly and should not be taken in any way as restricting the generality ofthe invention.

IN THE DRAWINGS

FIG. 1 is a schematic diagram representing a macro view of the systemarchitecture showing the main modules of the system as well as access tothe system;

FIG. 2 is a schematic diagram representing the communication flow fromthe sales module of the system to the search/directory module;

FIG. 3 is a schematic diagram representing the communication flow fromthe search directory module to the procurement module;

FIG. 4 is a schematic diagram representing the communication flowbetween the sales module and the procurement module;

FIG. 5 is a schematic diagram representing the general relationshipamong search parameters;

FIG. 6 is a schematic diagram representing a generalization of thedirect stock procurement functions;

FIG. 7 is a schematic diagram representing a generalization of theindirect stock (non-stock) procurement functions;

FIG. 8 is a schematic diagram representing the relationship among thedifferent aspects of the sales module and the procurement module;

FIG. 9 is a schematic diagram representing the relationship between theprocurement module and the sales module in respect of the purchase/salesorder processing functions;

FIG. 10 is a schematic diagram representing a post-negotiation functionof an embodiment of the invention;

FIG. 11 is a flow chart showing steps carried out by the system duringthe development of a set of seller offers; and

FIG. 12 is a flow chart showing steps carried out by the system duringnegotiation of a commercial transaction.

Referring now to FIG. 1, there is shown generally an embodiment of asystem 1 for facilitating e-commerce transactions. The system has threecomplementary components 2 to 4 that operate independently butco-operatively to streamline of the establishment, negotiation andexecution of commercial transactions. FIGS. 1-5 are schematic drawingsrepresenting an overview of these three complimentary components, thecontents of which will be clearer in view of the description explanationof the respective components below.

The described embodiment is particularly well suited to improving theefficiency with which complex international, intra-firm and domesticcommercial transactions can be conducted. The three complementarycomponents mentioned above and each in turn described in greater detailbelow, and are for the sake of convenience referred to as:

-   -   Macro/market search/directory    -   Micro/Sales module    -   Micro/Procurement module

The first component, a macro/market search/directory module 2, providesa mechanism by which signals originating from separate enterprises areaggregated. The second component, a sales module 3 (supply-sidecommunications module) is a mechanism by which each enterprise controlssignals sent to both the macro/market module 2 and/or other enterprises'procurement module. The third component, the procurement module 4 is themechanism by which the sales module signals can be captured from eitherthe macro/market search/directory 2 or separate micro/sales modules 3.

The three components provide the structure in which business processactivities can occur that includes:

-   -   Product search/selection    -   negotiation    -   post-negotiation

The first business process activity, product search/selection, involvesan identification of prospective partners to a commercial transaction.The negotiation step facilitates the negotiation or bargaining betweenmultiple parties as to the terms of a proposed commercial transaction.The post-negotiation function assists in the execution of thetransaction management and logistical functions that are necessary to beperformed to execute any contract which is established between partiesas a result of a successful outcome of the negotiation function.

The inter-relationship between the configuration of the three componentsand the business process activities that occur within the system isimportant. The structural mechanics of the components provide thefoundation of the model, and is designed in a manner to achieve asystem-wide equilibrium by providing a balancing of dynamic forces (thesecond dimension condition), while simultaneously seeking to maximizethe efficiency of the user and data inter-relationships in relation to‘user to system’ and ‘user to user’ contexts (the third, businessprocess dimension condition).

In practical terms, the equilibrium condition (at the most basic level)is satisfied by means of constructing the structure having the followingmechanical characteristics:

-   -   open and decentralized entry and exit for all system actors    -   decentralized distribution of key sub-system data processing and        management functions    -   instantaneous information and process data distribution        mechanisms    -   dynamic exchange/adjustment mechanisms

In the first respect, FIG. 1 illustrates how, in broad terms, the systemsatisfies the open access requirement. The search/directory module 2includes a search/directory component 5 together with an administrationcomponent 6 and a requisitions component 7. The functionality of atleast part of the search/directory module 2 is provided by anApplication Service Provider (ASP) connectable to the sales module 3 andprocurement module 4 by a communications network, such as the Internet.

The sales module 3 includes a catalogue/search requisition component 10,a registration component 11, a contract quotation component 12, atransport logistics services quote component 13, a negotiation component14, a quote manager component 15, and sales order management andtracking component 16. An order communications component 17 and ERPcommunications component IS enable communication between the salesmodule 3 and an enterprise resource planning (ER?) system 19 or likeelectronic data source.

Similarly, the procurement module 4 includes a reverse tender/quotationcomponent 30, a micro-chain external item data matching component 31, anon-stock component 32, a stock component 33 and a purchase ordermanagement and tracking component 34. An order communications component35 and ERP communications component 36 act to interconnect theprocurement module 4 and a further ERP system 37.

The sales module 3 and procurement module 4 are realized by conventionalcomputing apparatus and communication devices each including aprocessing unit and associated memory storage unit maintaining computerprogram code for causing the computing apparatus to execute the requiredfunctionality.

In this example, each of the sales module 3 and the procurement module4, and associated ERP systems, are located on the premises of separateselling and buying entities. In other embodiments, one or more of theentities may include both a sales module 3 and a procurement module 4depending upon the commercial activities of that entity.

All modules 2 to 4 of the system 1 interact with each other at a systemcomponent to system component level; i.e., buy to sell, sell to buy,sell to market, market to sell, buy to market, market to buy. In thatregard, each of the modules 2 to 4 includes a communications gateway,respectively referenced 50 to 52, to facilitate communication betweenthe modules 2 to 4. In addition, where a buyer or a seller does notpossess software to permit module to module communication, buyers andseller can access each of the modules 2 to 4 via a standard Internetbrowser by use of browser access clients, respectively referenced 60 to62. A browser access client can perform market/search, buy and sellfunctions by communicating directly with a particular component; it, amarket/search, buy or sell component.

FIGS. 2-4 illustrate how the configuration of the system 1 encompassesthe relationships that exist between the system's ‘market-related’business process activities (the vertical firm to market businessrelationships) and the system's firm to firm business process activities(the horizontal firm to firm business process axis). The juxtapositionof the two provides the basis for the spatial relationships that occurbetween:

-   -   markets    -   industries    -   firms, and    -   products        at the three stages (search, negotiation and post-transaction        management) in a commercial/transactional process.

The configuration of these parameters encapsulate the fundamentalbusiness process relationships that make-up a ‘virtual ‘supply-chain’;i.e., the structure is capable of overcoming information asymmetries inorder to seek and manage supplier-customer relationships among browserto system as well as system to system purchase and sale interactions.The practical implications of this are that a correct identification andcontrol of these relationships permits the construction of electronicsystems that are capable of generating predictable events resulting inexpected and rational outcomes that are in dynamic equilibrium (optimaloutcomes).

FIG. 2 illustrates the data flow from illustrative supply/sales modules70 to 72 to a market/search module 73. (Each entry in this figure alsoincludes a procurement module, respectively 74 to 76, and an ERP system,respectively 77 to 79). This data flow represents a micro (1) to macro(many) data relationship. The data originates from each firm'senterprise resource planning (ERP) system 77 to 79 or other equivalentelectronic data source. Each supply/sales module 70 to 72 selectsappropriate data and converts that data into a content/form that can beused by the market/search module 73.

This function provides the infrastructure for the market/search module73 to receive firm derived supplier/product information including dataupdates/refresh on a regular basis. The data flow and content isdetermined by a sales module based data direction/control function, aswill be explained below.

The principle device that controls product/item data flow to thesearch/directory module 2 is situated in the sales module 3. The controlissues relating to outbound data transmission turn upon solving for thebroad parameters:

-   -   What data (i.e., which product items)    -   Where that data is to be sent    -   How often

FIGS. 3 and 4 illustrate how a firm's product/sales item information(what) is sent to two classes of receiver. FIG. 3 shows data flowing tocomponents having a one to many (1:M) data relationship, i.e.,search/directories and marketplaces. FIG. 4 shows data being transmitteddirectly to other firms being a one to one (1:1) data relationship.

The data transmission functions of each sales module 70 to 72 includecontrolling mechanisms that allow sellers to restrict the data contenttransmitted to different receivers. For example, sellers will wish tosend a large number of their sales product items to marketplaces. Bycontrast, only selected items may wish to be transmitted to discretebuyers.

Control issues include the frequency of catalogue updates and will varyaccording to destination type. Search/marketplace data updates may berequired on a real-time basis because data will be viewed frequently bylarge numbers of viewers. On the other hand, product item updates sentto buyers (to refresh their supply-chain catalogues), will be much morerestricted in scope.

FIG. 3 is an extension of FIG. 2 and illustrates the movement ofdiscrete data from the search/marketplace 73 to the buyer's modules 74to 76. The purpose of this function is to provide a data savingmechanism whereby a prospective buyer can build a customized catalogueof numerous items selected from a search/marketplace module 2.

FIG. 4 also illustrates the transmission flow of an electronictransportation function. The transportation function involves themovement of a buyer from a search/marketplace module to a discretefirm's sales module. For example, upon selecting an item listed in themarketplace directory module 2, a buyer that wishes to purchase theitem(s) can elect to be transported (with data content) to a salesmodule. The data content that is transported with the buyer is derivedfrom products it has located in the marketplace/directory andappropriated to electronic requisitions.

As the buyer may be looking at products from more than one seller, thismay require the creation of multiple simultaneous requisitions.Therefore, simultaneous transport to multiple sales modules of differentseller is possible.

Both the procurement and search/marketplace modules make use of thesearch module 2 to provide a buyer with functionality that assists it inmaking a selection decision. The primary search mechanism of the searchmodule 2 is the search/directory component 5, which is designed toselect, group and list search results according to a user-selectedconfiguration of industry index, product classification, company/firmand geographical locator codes. All of the generic (non-product or firmspecific variables) indices and coding systems used are derived fromstandard indices recognized and administered by the United NationsStatistical Data Division and private and public statistical agencies.

The search/directory component 5 functions by searching mandatory andoptional parameters which the user must specify/select in defining thesearch criteria. The search/directory component 5 configures the user'sselection mandatory and optional search criteria. It produces a simplealgorithm that formats the breadth of the search to conform to thegoverning algorithm.

The search process functions by having the cross-relational algorithmlink classes of information. Some of the classes correspond to anexisting indexing system, other data classes do not. The data classesand corresponding indices are as follows: Data Class Index Industry(Broad) ISIC (2 digit level) Product goods HS (4, 6, 10 digit level)services CPC (3, 5 digit level) Brand Company Name parent subsidiaryRegion 13 Category Region Code Country UN 2 alpha code State/Province UNintra-country code ISDN-telephone area code Internat. ISDN code Port-Air/Sea/Inland UN Port Codes

Each specific product or service entered into the directory will have aseparate and unique identifier tag that is derived from theconfiguration algorithm. The search configuration algorithmdistinguishes between companies, products and brands having the same orsimilar attributes by arranging the relationships between attributes ofthe governing classes.

For example; numerous similar products (good or service) may fall withinthe same CPC or HS classification categories. Each particular productitem listed in the directory will inherit a unique identifier tag thatit derives from the totality of the classification attributes listed inthe table above. Even if a product is tagged to a particularmanufacturing or service providing enterprise operating across severaldistribution points, the same product offered across multiple outletswill take on a unique identifier tag for each sale unit.

Accordingly, in order to identify the precise origin of a product,geographical location identifiers can be attached to the product. Thesecan be further cross-referenced to other important geographicalidentifiers such as nearest ports, airports or distribution hubs allidentified by their respective international/domestic classificationcodes.

FIG. 5 illustrates how the search mechanism of the search/directorymodule drills down across four levels of organizational form, namely,Industry 80, Product 81, Company 82, and Brand 83.

The cross-relational attributes of the item identifier criteria meansthat items can be gathered together at various levels of aggregation anddisaggregation. Users can therefore enter the system and search eitherby broad product descriptors 84, industry classification, brand 83, firm85 or location 86 or any combination of these fields. It is thereforepossible for the search mechanism to generate directories and lists byany of these descriptors and classifications.

Moreover these lists or directories can be reported either by location,firm, brand and or industry. In addition cross-comparison of products isstraight-forward. Having generated the list of products in theappropriate catalogue, all the information about the products can bereadily compared, including reserve price, volume, productcharacteristics and specifications.

Internet search engines cannot by their very nature perform searcheswhich are able to most accurately and expediently identify prospectivecommercial trading partners—either sellers or buyers. At present mostorganizations will conduct searches having a particular type or class ofproduct in mind. Given the number of different types of information andproducts that may fall within the scope of a general search term, anorganization conducting a search for prospective business partnerstypically ends up wasting a great deal of time sifting and sorting amongrelevant and irrelevant search results.

The search/directory module 2 provides the ability to narrow the scopeof the search considerably using a mechanism that is capable of reducingthe search criteria to a level of specificity that accurately reflectsthe product being searched, and subsequently ranking these resultcriteria.

To improve this level of specificity a more precise means of conductinga product search is required for having a high degree of precision is bymeans of a search mechanism that conducts a database search for businessenterprises that sell products falling into a product's appropriateHarmonized Tariff Classification (HTC) Code.

The HTC system is a classification index that is internationallyrecognized and used by customs authorities around the world for theclassification of outgoing and incoming goods crossing international ornational borders.

The HTC System operates as follows:

4 digits: represent the specific industry

+2 digits: represent 6 broad product class

+2 digits: represent S specific product class

+2 digits: represent 10 specific products

The search/directory module 2 provides prospective buyers with theability to look up the HTC Code corresponding to the product type(general or specific) of the product they wish to search. Each databasesearch by HTC Code is cross-referenced to industry level. For example,the Standard International Trade Classification system (SITC) andbusiness enterprise name criteria enable the searcher to further narrowthe search criteria. Conversely, all searches by business enterprisename or general product description will be cross-reference to the HTCCode. Therefore, the common search criteria of all products contained inthe product search database are each product's discrete HTC Code. Thuswe will build the first product search engine based upon the HTC Code.

The search/directory module 2 uses the HTC system as well as otheroverlaying parameters built into the search mechanism, thus creatingincreased levels of functionality and dynamism. The results are to becategorized by a ranking system based upon preferential outcomesselected by the user.

The search/directory module 2 is preferably case sensitive and requiresat least one field to contain data before the search can be activated.Once the search criteria are completed the user ranks the searchnumerically. This ranking of search parameters creates dynamic outcomesnot available with current search mechanisms. A cross referencingmechanism matches procurement requirements with search items based onproduct type, price, volume, payment terms, geographical location.

Additional flexibility may be built into this search mechanism wherebyno fields require mandatory inputs. Additional fields can benominated/included at the time of the search to create an increasedspectrum of result criteria. This increased level of dynamism with thesearch provides for the user the optimum outcome. This may result inunexpected outcomes based upon expected values.

The greater the specificity of the search criteria ultimately providesexpanded search results generated from the flexibility created fromwithin the search mechanism.

The search function can be supplemented by expert system functionalityable to categorize and rank search outcomes according to the userspreferences.

The procurement module 4 is a processing mechanism that handles thedemand-oriented procurement requirements of a single firm. It matchesthe firm's demand requirements with product and service items that itmust obtain from sources external to the firm. The search/directoryfunctions of the search/directory module 2, operating in conjunctionwith procurement module functions of the procurement module 4, providesthe specific sources of products and services that the firm can procure.

Procurement items are obtained from three sources of supply within thesystem:

-   -   Items saved from the marketplace/directory searches    -   Items saved from sales modules searches or transmission    -   Items entered directly into the procurement module by non-system        browser access clients

These three external sources of items provide the pool (supply) ofpotential items for purchase by the firm that may be used to satisfy thedemand requirements of the firm.

However, a firm's procurement requirements are derived from factorsinternal to the firm arising from its operating and productionactivities. The procurement module 4 distinguishes between two broadtypes of procurement requirements, namely stock items and non-stockitems, respectively handled by the stock component 33 and the non-stockcomponent 32.

Stock item requisitions are made as a result of the depletion of productitems (inventory) that a firm uses direct result its manufacturing orproduction activities; i.e., are items that are transformed and/orundergo a value-adding process in the course of producing anotherproduct. Non-stock items are products that a firm consumes as anindirect result of its daily activities. Non-stock items includemaintenance, repair and overhead (MRO) items such as stationary,computer support items etc.

In addition, the procurement module 4 handles two broad types ofpurchase orders:

-   -   Blanket (or standing) purchase orders    -   One-off (or standard) purchase orders

The procurement module 4 coordinates the firm's internal demandrequirements and provides a mechanism by which these internal demandrequirements can be matched with the externally acquired pool ofrequired items.

FIG. 6 is a diagram of the general process flow of the direct stockprocurement process. The demand for stock items is derived at step 100from processes that occur within a firm's back-office systems (usuallyan ERP system 101). The ERP contains a list of direct-stock productitems and indicates when stock must be replenished. The procurementmodule 4 functions by matching the firm's direct-stock product itemrequirements with:

-   -   items supplied by current suppliers    -   items supplied by potential suppliers

The method and source of the matching process depends upon whether:

-   -   an existing blanket purchase order is to be extended    -   a new blanket purchase order is to be created    -   a one-off purchase order is to be created

Additional functionality permits the procurement requisition to befulfilled to conform to business process requirements as to whether:

-   -   a quotation price is required    -   a tender process must be followed    -   and whereby inbound quotes and tenders are determined on the        basis of a dynamic, reverse negotiating process.

The supply of stock items is derived from the three external sourcesidentified above. The method of matching is dependant upon the businessprocess functions which are required to be met under the particularcircumstances of the specific procurement requirements. Once thepurchase order is made at step 102, sent and confirmed by suppliers 103and 104, its confirmation is processed back into the ERP system 100.

FIG. 7 is a diagram of the genera) process flow of the indirect ornon-stock procurement process. The demand for non-stock items is derivedfrom processes that occur as a result of consumption as a result oforganizational and operational factors within a firm. It is frequentlythe case that inventory management of consumption of non-stock items arenot as sensitive and accurate as is the case with stock-items. Thedemand for non-stock items is derived from specific operating units 110to 112 within the firm. The list of non-stock product items within theERP 101 is generalized to product type and category rather than at ahighly specific level as it is with stock items.

Demand for non-stock items is derived from members of the firm whorecognize replenishment is required. Requisition of non-stock items isusually initiated by the member rather than the ER? or back-officefunctions (but is may be the case that the ERP initiates some purchaserequirements).

The procurement module 4 provides a mechanism by which a non-stockrequisition can be created at step 113 by the initiating member. Therequisition is formed according to the results of a matching of therequisition product item requirements with:

-   -   items supplied by current suppliers    -   items supplied by potential suppliers

Additional functionality permits the procurement requisition to befulfilled to conform to business process requirements as to whether:

-   -   a quotation price is required    -   a tender process must be followed    -   and whereby inbound quotes and tenders are determined on the        basis of a dynamic, reverse negotiating process.

The supply of non-stock items is derived from the three external sourcesidentified above. The method of matching is dependant upon the businessprocess functions which are -required to be met under the particularcircumstances of the specific procurement requirements.

Once the purchase order is made, sent and confirmed by the supplier, itsconfirmation is processed back into the ERP (back-office) systems.

FIG. 8 is a diagram illustrating the operation of the sales module 3shown in FIG. 1. The sales module 3 is a device that performssupply-side functions that either ‘stand-alone’ to configure and executea sales transaction; or function in concert with a procurement module toprovide an increased level of automated transaction processing. A buyercan be transported to the sales module 3 via the transportationmechanism from a search/directory module 2 or procurement module 4;alternatively, a buyer can enter the sales module via direct browseraccess.

In all cases, the buyer-client selects a list of items according to aseries of business case rules or navigational choices and creates aproduct requisition form. The item selection process will, byimplication, generate a list of items that the buyer-client configuresaccording to its requirements. If transported from a procurement module4 or search/directory module 2, the buyer will have partially configureda requisition. The requisition contains data to be used for the purposesof obtaining a quotation, demonstration order or outright purchase(negotiation).

The item selection list, by implication, is the same data that will becontained in a sales order invoice. The sales order is the configurationof data that will be processed as the final sales terms and conditionsbetween the buyer and seller. The sales order is also processed in theERP as a discrete transactional outcome.

The population of item data within the sales module is derived directlyfrom data obtained from the ERP (thus avoiding data duplication).

Upon completing a requisition, a registration process must occur beforethe buyer can proceed with the transaction. If the buyer has beentransported from a procurement or search/directory module, registrationis automatic. The registration data is matched to customer/sales relateddata in the seller-firm's ERF consistent with, and to be used for,customer relations management (CRM) functions/purposes.

At this stage, the requisition is made according to an unadjusted orderprice. This is the base price upon which further price-relatedadjustments will be made subject to the functions described below, Aprovisional sales order number is allocated to the requisition (nowbecoming a provisional sales order).

The provisional sales order is provisional for several reasons. Onereason is that its initial purpose is derived from that fact that thebuyer-client may wish to obtain a quotation only. The seller's quotationprice must be competitive, but not be the last price-related say; i.e.,further price adjustments may be made at a later step in the process;i.e., final negotiation.

At the quotation stage system generated adjustments for:

-   -   volume purchases (ERP data)    -   customer status discounts- i.e., if the customer is known and        good- a discount may apply.

The system computes the quotation price by taking the unadjustedprovisional sales order price and then deducting appropriate rebates.

No price adjustment is mandatory- only occurs if volume and customerclass rebates apply. The system computes the quotation price. Aquotation number is generated by the system and the provisional salesorder is stored in the system under the system assigned quotationnumber.

The buyer is provided with the quotation number and the quotationdetails and the quotation amount. The buyer should be able to leave andaccess the system calling up the provisional sales order at a later timeby inputting a password and sales order number.

The buyer may, before or after viewing the quote, change their mind andwish to re-configure their order. Functionality allowing the buyer toadd/delete items in the sales order list is provided.

If a buyer selects a request for quotation, a second, parallel,quotation function is set in motion being a quotation for ancillaryservice contracts such as transport/logistics, insurance, finance andinspection.

The services contract quotations are calculated using system dataderived from the core sales contract plus:

-   -   shipment details, including price, etc.    -   cargo type    -   cargo weight and volume data, etc.

The sales module automatically determines whether the sales contract isdomestic or international by conducting a cross-check between country oforigin (i.e., seller's location) and country of destination.

The buyer (or ERP) will fill in the additional required information.

-   -   Place of loading (domestic)    -   Place of discharge (domestic)    -   Port of loading (international)    -   Port of discharge (international)    -   Inland freight required from port to plant or air)    -   Container type-general or refrigerated )    -   Estimated time of departure (ERP lead-time+one week)

The buyer will check the information and select the send quote toshipping agent or forwarder. The shipping agent will be sent an emailnotifying him that a new RFQ has been posted to his URL/access site.

The vast majority of international and domestic commercial transactionsundertaken between business entities (B2B transactions) fall into thecategory of intermediate goods trade. Intermediate goods trade refers toB2B trade of primary, or secondary non-finished goods requiring furtherprocessing to create a marketable finished product.

International and domestic intermediate goods trade is dominated by thepricing decision. The pricing-decision is the core decision of thetransaction process. It involves a price-setting decision on the part ofthe seller, and a price-bidding decision on the part of the buyer. Theultimate buyer will undertake a comparative and competitive marketanalysis and, subsequently, make a conscious and calculated pricingdecision. A seller, on the other hand, will set an indicative price,which, under typical circumstances is broadly calculated on a cost plusprofit basis. The price spread between the seller's preferred sellingprice and the buyer's offer price is the negotiable margin.

However, in addition to price, intermediate goods transactions arefrequently complex and additional factors are part of any transaction.These factors include, for example:

-   -   volume    -   the method of payment, i.e.,        -   pre-payment        -   letter of credit        -   documentary collections        -   open account;    -   credit terms; i.e.,        -   30, 60, 90, 120, 180 or more days    -   credit rates of interest    -   transport and logistics charges    -   insurance charges    -   inspection charges    -   banking and finance related charges    -   country and credit risk adjustments

In an international trade negotiation buyers and sellers effectivelynegotiate a transaction involving multiple factors, which generallyinclude the following variables, though may include several others:

-   -   Price    -   Volume    -   Payment Method    -   Time terms    -   Credit terms        Additional negotiating terms can be either added or excluded        from the negotiation depending on whether the transaction is an        international, domestic or intra-firm (international or        domestic) negotiation. The transaction embodiment provides the        ability to negotiate over a range of variables. It operates in        real-time and is capable of being used by multiple users        simultaneously. All functions are conducted in a systematic        manner that is consistent with the well-known international        standards Incoterms 2000 and the CP 500 requirements.

The system 1 provides a mechanism by which buyers and sellers cannegotiate an agreed set of contractual outcomes covering price and allprice-related aspects of the contract.

A feature of the system 1 is that it can operate at three levels:

-   -   As a multi-buyer and/or multi seller multiparametric auction    -   As a single buyer to single seller multiparametric negotiation        game.    -   As a simultaneous combination of the multiparametric auction and        the multiparametric negotiation game.

The auction aspect of the system 1 may use any one of the standardauction design rules, which will be chosen by the seller in advance. Forinstance the seller may choose to sell the product using the rules ofany one of the “English” auction, the “Dutch” auction, the “sealed-bid”auction or the “Vickrey” auction. The type of auction will be chosen bythe seller and communicated to the buyers in advance. However, the majororiginal method by which the auction is instigated in the transactionhub comes from the method by which sell offers and buy bids are enteredand resolved and the number of variables included in the auctionprocess.

(a) Setting the Seller's Reserve Offer

In order for the system 1 to begin to perform its operations, the sellerspecifies values for the relevant trading parameters over which it hasinfluence in an international trade negotiation. In an internationaltrade transaction the seller is not only interested in price, but alsothe following additional variables: volume; payment method; time terms;and credit terms (as well as, perhaps, several others).

For example, a seller may be prepared to accept a lower price if theseller can sell a greater volume or get more favourable payment terms.Therefore, it is usual for a seller, during the course of a negotiation,to make expected value calculations over a wide range of differentcombinations of these variables. The system 1 provides an automatedprocess of preference calculation by allowing sellers to transparentlyreveal to themselves the values placed on the various components of anyoffer and then to verify that their preference ordering is consistentand non-reflexive.

In determining the final outcome of the negotiation, it is possible thatthe computer optimizing algorithm used in the system 1 will generate acombination of price, payment methods, credit terms, credit rates ofinterest etc that was not be anticipated or thought of by the humanbeing who sets the parameter values for the sell offer. Because thereare many thousands of possible combinations and permutations, a partlyor completely non-reflexive preference ordering over all preferences maybe generated. The seller (with the aid of the computer) identifies allthose possible combinations of the parameter values that are of equalexpected value, most particularly those covering the reserve offer. Thatis, once the seller has chosen one combination of parameter values thatrepresent the preferred reserve offer (O₁), the seller should then beable to identify readily other parameter values that generate anidentical expected value calculation such that a second reserve offer (0₂), third reserve offer (03), and other reserve offers are of equivalentvalue.

In an exemplary embodiment shown in FIG. 11, a seller enters values forall variables of its most preferred reserve offer (O˜) at step 200. Thisis the offer that the seller would be happy to accept if it were offeredby any buyer.

The seller is required to enter a value for each of the following, wherethey apply:

-   -   price    -   volume and volume price reductions, where they apply    -   the method of payment, i.e.        -   pre-payment        -   letter of credit        -   documentary collections        -   open account;    -   credit terms; i.e.        -   30, 60, 90, 120, 180 or more days    -   credit rates of interest    -   transport and logistics charges    -   insurance charges    -   inspection charges    -   banking and finance related charges    -   country and credit risk adjustments

As part of this initial value setting, the seller indicates at step 202the precise fractional relationship between the change in price andchange in each of the variables that directly (in either a linear ornon-linear relationship) affect the determination of price:

-   -   volume;        The seller indicates the percentage volume discount on price for        a range of different volumes, all other variables held constant        (this will generate a simple linear or non-linear function of        price change as a function of volume)    -   method of payment;        The seller indicates the percentage price increase, from the        base price, contained in 0 ₁, associated with each payment        method beyond pre-payment such as letter of credit, documentary        collections open account, all other variables held constant        (this will generate a linear or non-linear function of price        change as a function of payment method)    -   credit terms;        The seller indicates the percentage increase in price associated        with the increase of time beyond 0 days such as 30, 60, 90, 120,        180 or more days, all other variables held constant (this will        generate a simple linear or non-linear function of price change        as a function of time terms)    -   credit rates of interest;        The seller indicates the percentage increase in price associated        with interest penalties over time, all other variables held        constant (this will generate a simple linear or non-linear        function of price change as a function of interest premiums).

The system 1 then determines an expected value for this sell offer, sayv1 at step 204. At the conclusion of step 1 the seller has specifiedinformation on the preferred reserve offer and the way importantprice-related variables such as volume and method of payment impact uponprice change. With this revealed preference information, the system 1 isable to generate all possible combinations of the parameters that willgenerate offers of equal expected value using a standard maximumlikelihood algorithm.

The system 1 now gives the seller a chance to check revealed preferencesby allowing the seller to enters, at step 206, values for all relevantvariables, but with a slightly higher price and altered values, whererelevant, for other terms, say for example less favourable paymentterms, representing an alternative offer, (0 ₂) which is identical inexpected value to v₁=0 ₁ 0 ₂. Importantly this offer is considered to beof equal value in the sense that the seller is no worse off than in thecase of 0 ₁.

Using the maximum likelihood algorithm the computer is able to check thenew values against the preferences revealed in Step 1 for consistency.The system 1 will indicate to the seller if there are anyinconsistencies and allow the seller the chance to correct inconsistentvalues. After repeating this exercise a small number of times, thecomputer maximum likelihood algorithm will generate a complete set ofnon-reflexive preference orderings.

Seller now repeats Step 2 and, at step 208, enters values for allrelevant variables, but with a slightly higher price and altered valuesfor other terms representing an alternative offer, (0₃) which isidentical in expected value to v₁=0 ₁=0 ₂=0 ₃.

Once this process is completed, the seller has effectively established asystem of functional relationships between variations in a key tradingparameter and one or more other trading parameters which may berepresented as a system of simultaneous equations whereby price is afunction of a range of variables and changes in price are functions of arange of other, but related variables. Using any one of a number ofstandard maximum likelihood techniques such as Newton-Raphson or theGenetic algorithm parameter approach, a matrix of equivalent valuecalculations can be generated, at step 210, for every possiblepermutation or combination of the variables included in the sell offerprocess. This means that the complete equivalence of value will berevealed for every possible combination of price and the various otherterms identified above as part of this reserve offer calculation.

At the end of this process we have, at step 212, a complete set ofseller offers 0 ₁, . . . O_(n), covering all possible combinations ofthe trade variables that generate offers that are equivalent in value,v₁, This means that it is relatively straight forward by essentiallyinterpolating between O₁, . . . O_(n) in a multi-dimensional space, tocompare any bid from any buyer and determine whether it is above theseller's reserve offer, v₂>v₁, or below the reserve offer, v₂<v₁,irrespective of the composition of the offer.

EXAMPLE

Consider a simple hypothetical example. Assume that a seller entersinitial values for the preferred reserve offer which include a price of$10 per unit, to be paid by letter of credit on 60 days at an effectivecredit rate of interest of 10%. As part of the initial value setting theseller also indicates the percentage price increase required if thepayment method is not letter of credit but rather documentarycollections or open account, or if the payment is by letter of creditbut on less favourable time terms such as 90 days. With this revealedinformation the system 1, using a maximum likelihood estimator, is ableto identify other equivalent reserve offers which, for example, might bea price of $11 per unit by letter of credit on 90 days at an effectiveinterest rate of 12%. In other words the computer is able to determinedifferent combinations of price, payment method, time terms etc that areof equivalent value to the seller's initial reserve offer and allcombinations of the variables that are superior and inferior to thereserve offer.

Once the seller has completed the exercise of determining its reserveoffers, the seller may now choose to indicate that it has product tooffer for auction, or sale and may begin negotiating directly with apotential buyer, or do both.

The Single Seller Auction Scenario

Having specified that it has product to sell and it wishes to proceedwith an auction, the seller now posts this information to the productcatalogue.

Step 1: Seller Indicates the Type of Auction and Auction Rules

The seller may choose to sell the product using any of the “English”auction, the “Dutch” auction, the “sealed-bid” auction or the “Vickrey”auction rules.

Step 2: Bids come in from Buyers

As seen in Figure 11, bids are received from prospective buyers at step220. The auction remains open for a specified time or until there is abid of value v_(n)≧v₁ at step 222. In this case, a commercialtransaction between the seller and buyer is initiated, at step 224. Inthe same way that the seller specifies values for the variables: volume;Payment Method; Time terms; and Credit terms, etc., the buyer must alsoenter a bid that indicates values for each of the relevant terms to aninternational transaction. Depending upon the rules of the auction,certain information will be revealed to all market participants.However, as each unsuccessful bid comes in, the owner of that bid willreceive feedback at step 226 about their bid and what they might change,or increase at step 228 in order to make the bid closer to the reserveoffer of the seller. For example a buyer might receive advice to eitherreduce time terms from say 90 days to 60 days or slightly increase priceor some combination of the two.

Note, the reserve offer of the seller is not revealed to the bidders. Atthe end of this process, the product will be sold to the highest biddermeasured by the extent to which the winning bid exceeds the reserveoffer. Where there are two identical winning bids the bid received firstwill be the successful bid or the market did not clear. When the marketdoes not clear then the seller has the choice of beginning the processover again or, alternatively, to begin negotiating directly with one ormore of the potential buyers.

The Single Seller-Single Buyer Negotiation Scenario

In many real world trade situations the buyer and seller are well knownto each other and often have a long-standing trading relationship. Inthese cases they may wish to begin to negotiate directly with eachother. The system 1 designed to deal with just such situations. In thissense the system 1 provides the mechanism to undertake a bilateralbargaining game. The bilateral bargaining game may take one of severalforms and again the rules covering the negotiation would be agreed inadvance of the formal commencement of the bargain. Importantly, in thebargaining games/negotiation scenario, the buyer may reveal bids in amanner similar to the way the seller reveals preferences. In thetransaction hub the bargaining/negotiation game may take one of thefollowing forms:

-   -   an alternating-offer bargaining game instigated by the buyer        (requiring real time on-line access by both buyer and seller)    -   an alternating-offer bargaining game instigated by the seller        (requiring real time on-line access by both buyer and seller)    -   a single-offer bargaining game instigated by the buyer        (requiring real time on-line access by the seller only)    -   a single-offer bargaining game instigated by the seller        (requiring real time on-line access by the buyer only)    -   a cooperative game instigated by either party and with an agreed        arbitrator (the transaction hub via the computer itself).

In these bargaining games, an international trade transaction operatesby means of a multiparametric negotiation, as explained above. Thebargaining is not constrained to a single variable, price, but ratherembraces all the variables relevant to an international tradetransaction. In this case, though, the bargaining framework involves acooperative game instigated by either party and with an agreedarbitrator, whereas the transaction hub is both the vehicle throughwhich the negotiation occurs and the arbitrator to the negotiation.

In the bargaining/negotiation games buyers and sellers can negotiateover the whole range of international trade terms identified above. Theprocess may begin with either the seller, who has set the reserve offersO₁ to O_(n), with equivalent value, v₁, or with the buyer, whoundertakes a similar process to the seller, in order to specify maximumbids, B₁ to B₂ with equivalent value, v_(k) beyond which the buyer isnot prepared to go. As long as v_(k)≧v₁ then a bargain can occur andthere is room for negotiation.

Where v_(k)≧v₁ then a bargain/negotiation may take place and thecomputer will feed back to both sides the need to change values. Forexample, hypothetically, the computer may indicate to the seller toslightly lower price and the buyer to slightly improve payment timeterms from say 90 days to 60 days.

The buyer and seller may bargain themselves, with advice from thecomputer, or let the transaction hub assist them to come up with asatisfactory solution that is at least no worse than the outcome theywould have achieved bargaining on their own, and most likely to be morefavourable to both parties, all other things held equal.

In order to assist in the arbitration process, the seller and the buyereach reveal some additional information relating to the terms over whichthey are negotiating.

Both the seller and buyer will each have to allocate simple arithmeticweights to each of the terms over which they are negotiating. Considerthe following simple example: Payment Credit Time Interest Price MethodTerms Terms Σ A b C D 1

The weights a+b+c+d=1. This information, plus the information revealedby the seller and buyer when specifying their respective pricingfunctions will be used by the system 1, using a genetic algorithmparameter framework, to find the most favourable outcome over price andall related terms to the negotiation. It is possible for there to bemore than one outcome. Where there are several outcomes of equivalentexpected value then the computer will choose one at random.

Once the system 1 has been in use for some time and has built up aprofile of previous successful transactions this information can beinterrogated to assist in facilitating further successful transactions.Desirably, neural network functionality is used to augment theoptimization process.

It will also be possible for the seller to undertake both an auction anda negotiation simultaneously, and to undertake multiple negotiationssimultaneously.

Post-Negotiation Transaction Processing

Direct Purchase and Sales Order Processing

This section describes the process flow and data specifications for theconfiguration and transmission of purchase order and corresponding salesorder data between a buyer's procurement and seller's sales modules.

These functions originate from mechanisms contained within theprocurement module 4 and sales module 3. After a purchase order (PO)draw-down (for a one-off or blanket purchase order (BPO)) has occurredwithin the ERP 37 (or is manually interfaced), the PO details appear inthe procurement module 4 ready for processing. This outbound PO is to bedelivered from the originating procurement to the appropriate salesmodule.

The procurement module 4 recognizes and distinguishes between outboundPO's to be delivered to suppliers that do not have a sales module aswell as outbound PO's to be delivered to a sales module.

The buy-side administrator will receive the P0 (in the normal course ofevents, which will appear in the buy-side outbound P0 interface). Theadministrator will check the order (i.e., requisitioned items) andseller details. If all appear to be correct and no critical data hasbeen omitted from the order, the administrator selects the ‘processorder’ function.

The ‘process order’ function will activate a process whereby the PU datawill then be transmitted to the appropriate sell-side platform where itwill be received and processed (on the sell-side platform) in a mannerdescribed below.

The sales module 3 contains functionality that enables the receipt ofinbound purchase orders in the form of inbound sales-orderadministration functions. Inbound P0's (i.e., on the sell-side) arepresented to the system administrator via the inbound sales orderscreen. The system administrator performs an order approval process. Thesell-side administrator checks the order details and seller details. Ifall appear to be correct and no critical data has been omitted from theorder, the administrator selects the ‘process order’ function. If theorder appears to be correct, it can be processed to the ERP. A salesorder confirmation will then be transmitted back to the buyer.

The confirmation will be communicated back to the buyer as an orderstatus code. For example;

-   -   accepted orders=status code I    -   amended orders=status code 2    -   rejected orders=status code 3

If the order is not accepted, the functionality below will be required.In some circumstances, the seller may not be able to fulfill the orderas presented. The seller/administrator has two options:

-   -   amend the order    -   reject the order

Functionality to permit the seller/administrator to change/amend thevolume requested by the buyer in the original P0 is provided. Theseller/administrator will select the ‘amend order’ button. Selectionwill enable the volume field to be changed. If the order volume ischanged, the amended order volume change must be communicated back tothe buyer's procurement module.

The data, therefore to be communicated back to the buyer's procurementmodule is the changed volume and status code 2 data. Once received bythe buyer, existing functionality already contained in the buy-sidesystem is activated.

If the order is to be rejected, the seller/administrator will select the‘reject order’ button. Selection will terminate the transaction. This iscommunicated back to the buyer.

The data flows inherent in the order rejection function arestraight-forward. It requires that the appropriate status code; i.e., 3,be transmitted back to the buyer's procurement module.

Messages back to the buyer's procurement module 4 appear as inbound P0confirmation functions. An order that has been accepted by a salesmodule is communicated back to a procurement module as an order having astatus code=1, being a straight acceptance. The buy-side administratorcan view the order details and then proceed with the ‘process order’function which will process the order back into the buyer's ERP 37.

An amended order will be communicated back to the procurement module as:

-   -   a status code 2 and    -   including the amended volume data

The amended order is communicated to the buyer/administrator in thebuyer-side ‘inbound notifications’ screen as an ‘amended purchase order’in the ‘inbound notifications’ interface of the procurement module. Thebuy-side administrator can view the order details:

-   -   proceed with the ‘process order’ function (which will process        the order back into the buyer's ERP), or;    -   terminate the order (and begin conventional non-online        discussions with supplier- this may involve breach of contract        at this stage and require manual intervention.

A rejected order will be communicated back to the buy-side platform as astatus code 3 rejection. The rejected order is communicated to thebuyer/administrator via the buyer-side ‘inbound notifications’ screen asa ‘a rejected purchase order’.

-   -   This will constitute a breach of contract and require manual        intervention.        Post-Negotiation

In the post negotiation phase of the transaction, as illustrated in FIG.10 various ancillary transaction pre-conditions and requirements must besatisfied before the core contract is executed. Negotiated contractrequirements must be coordinated and performed before the movement ofgoods can occur.

The core contract has terms and conditions negotiated between theparties to a sales contract. These may include:

-   -   parties to the contract,    -   description of the goods,    -   volume    -   price    -   payment terms

The terms upon which payment is to be made from the buyer to the selleris the link between the core contract and several related contracts arelikely to be made with third parties. Although these relatedsub-contracts facilitate the ultimate execution of the core contract,this core contract is of course executed according to the payment termsspecified in the core contract. In essence, proper execution of thesub-contracts effectively acts as “conditions” to the core contract, andmust be satisfied by the appropriate party.

These appropriate parties are respectively involved in variouspost-negotiation functions. These include:

-   -   transport and shipping    -   insurance    -   inspection    -   credit and banking

In a mechanistic sense, if the satisfaction of the core conditions whichcorrespond to each of the sub-contracts is incorporated within anautomated business process in a logical manner, the sequentialsatisfaction of the sub-contracts can be viewed as a lock-and-keymechanism. This sequence can be formatted in a manner to ensure that theautomated process does not occur without the proper checks and balanceshaving taken place.

The lock and key logic underlying the automation of the post-transactionconsolidation process is also critical to establishing the precise pointat which the risk of loss, ownership title and payment obligations passfrom the seller to the buyer.

Taken one step further this is also the precise point in the automationprocess at which a direct interface with external “digital” bankingsystems can be established and, in accordance with contractual terms,instructions to shift funds from the buyer to the seller can occur.

Finally, the above also implies that it is this point in the businessprocess at which financial data can be allocated within the businessprocess back into the buyer and seller's internal financial managementand accounting systems.

Prior to the negotiation, the buyer inputs information relating to itsidentity. In addition, by selecting a product, key product informationis identified by the system relating to the precise identification anddescription of the goods the buyer wishes to purchase. At the conclusionof the transaction negotiation, offers submitted by the buyer will beeither rejected or accepted by the program. An offer that is accepted bythe program will contain all the core terms of the sales contract being:

-   -   identities of the parties to the contract    -   identification of the subject matter of the contract    -   price, volume and payment terms

This information will be consolidated and form the content of a proformaInvoice which the seller sends to the buyer to confirm receipt of theorder and acceptance of the terms offered. All data is already stored orgenerated within the system.

At this point in the process, the core contract is concluded and theinfluence of the several sub-contracts (mentioned above) dome into play.

As mentioned above, each of the sub-contracts performs an important roleand functions as “conditions” which must be satisfied in the course ofexecuting the terms of the core contract.

In order to automate and coordinate the sequencing of pre-shipmentcontractual requirements, embodiments of the invention involve apost-transaction processing mechanism. The described embodimentcoordinates, integrates and sequences the consolidation, generation andrespective submission of a purchase order by the buyer to the seller,and the issue of an invoice from the seller to the buyer.

Under the rules of commercial trade (such as Incoterms 1990 and 2000 andthe UCP 500), these conditions can also be arranged in a sequentialfashion. If these conditions are automated within a process the proceedsin a stepwise fashion, the entire post-transaction execution process canbe logically and systematically managed over time.

Unlike the transaction negotiation that can occur instantaneously, atime element is introduced into the post-transaction managementfunctions. Each of the conditions can be configured such that, in astepwise fashion, the proper satisfaction of each condition over timeensures that the core contract conditions are recognized as having beensystematically satisfied by the system.

A post-transaction management system assists the user to monitor theprogress of the functions as they are entered or activated within thesystem.

The post-negotiation process incorporates coordination functions thatare governed by:

-   -   the estimated time of departure (shipment of the product from        the contracted port or point of loading/shipment)    -   logistical aspects of the transaction must be coordinated with        the execution of agreed financing terms based on Incoterms 2000        and/or UCP 500.

The relationship between the logistics and shipping (by any relevantmode of transport) and the connectivity with the payment of thatshipping function is the “trade trigger”. The trade trigger is ofcritical importance to both the seller and buyer, as it determines thepoint in time within the contracted transaction process in which titleto the goods (and thus risk exposure) passes from one party to another.

Depending on the terms of the core contract negotiated between theparties, the fundamental conditions which may require to be satisfiedmay include:

-   -   credit and finance    -   transport    -   insurance    -   inspection

FIG. 9 is a schematic diagram representing the relationship between theprocurement module 4 and the sales module 3 in respect of purchase/salesorder processing functions. This figure illustrates the main categoriesof conditions which may require satisfaction before execution of thecore contract can be seen as proceeding within the scope of theagreement.

Each of the oval figures in the diagram represents a sub-contractcondition which must be satisfied in the post transaction phase of theprocess managed by the search module 2, sales module 3 and processingmodule 4 of the system 1. Each of these conditions, in turn, can beviewed as a “trigger”. When appropriate data is interfaced into theprocess, a condition is satisfied which, in turn triggers the process toproceed to the next condition.

The final step in the transaction execution process links thesub-contract execution functions to a banking function. An importantstep in the process is the issuance of the official shipping document,the bill of lading or air weigh-bill. These documents are viewed in lawas being documents of title which regulate the time at which risk ofloss and passage of title to the property occur relative to the terms ofthe core contract.

Passage of these documents between the shipper, seller and buyer take onthe added function of signalling the time at which the right of theseller to receive payment from the buyer occurs. The most important dateis the date of issuance of the relevant shipping document.

The point in the business process at which the actual issuance time isentered into the system also represents that point at which the buyerbecomes legally obligated to make payment to the seller (either now orat a future time). This importance of this event is that automatedbanking functions can now be activated.

Each of the oval figures in the diagram represents a sub-contractcondition which must be satisfied in the post transaction phase of theprocess. Each of these conditions, in turn, can be viewed as a‘trigger’. When appropriate data is interfaced into the process, acondition is satisfied which, in turn triggers the process to proceed tothe next condition.

Data interfacing and integration is a central function of thepost-negotiation aspect of the described embodiment. The system 1 hasbeen designed to reflect a logic that is influenced by two underlyingprinciples:

-   -   simple logic structures in order to permit easy data        manipulation and technical programming; while at the same time,    -   maximizing process efficiency and accuracy.    -   The system functions by:    -   coordinating and combining data from internal and external        sources    -   processing data combinations and generating new data    -   consolidating simple data with generated outcomes    -   sequencing the data manipulation and coordination functions        according to time and other conditional factors

The system 1 performs the data interfacing and integration functionsdescribed above by means of a central coordinating device that controlsdata interface and data distribution timing and sequencing. This device,in effect, controls the logic that drives the system's internalfunctions as well as external systems and users. Although the overallsystem 1 performs a number of discrete operations, these operations areprompted or controlled by the central coordinating mechanism which is,in turn, tied to data interfacing.

In order for the overall system 1 to function properly, it shouldideally perform systematic data retrieval and storage functions. Thesefunctions are made more complex given the differing sources of data. Thedata used includes:

-   -   simple data which is not manipulated or transformed, but is        necessary to the transaction    -   system generated data (originating from simple data that is        transformed)

This data is entered from several system interfaces (or sources). Thedata input via all interface sources is either stored in database form(and is used at some future time) or is used in an immediate processingfunction.

-   -   The sources of data are:    -   real-time data originating from user interfaces    -   system generated data originating from a processing/computation        function    -   data originating from interface with intranet systems    -   external data originating from interfacing with other Internet        sources        Given the various sources of data and the differing time        requirements for its use, the system performs and coordinates        numerous data prompting, retrieval and allocation functions.        This provides a foundation for the more complex integration        functions which are described below.

Whereas data sourcing and distribution is one integration-relatedfunction, the system performs integration functions that proceed at ahigher level of complexity. At this level, an underlying systems logicis used to combine technical simplicity in the data configurationprocesses (described above) with process efficiency considerations. Itis at this level of the integration process where business transactionlogic is combined with the invention's data logic.

Enterprise resource planning (ERP) systems are computer and databasemanagement systems. ERP systems assist business organizations byimproving internal process efficiency by linking databases that containan organizations supply chain related activities what the organization'smanufacturing planning, finance and administration functions.

ERP systems do not allow for integration of information relating toexternal business transactions.

The described embodiment of the system 1 includes an interface mechanismthat allows for the coordination of information between “back-end”computing systems and “front-end” marketing and transactionalactivities.

The interface component uploads relevant data from the host systems:

-   -   product item master database    -   customer master database    -   manufacturing and planning master database

This uploaded data is consolidated and distributed to the appropriateInternet modules; that is, product inventory/display modules,transaction hub module.

Further, the described embodiment of the system 1 consolidates anddistributes data and information generated from Internet functionsincluding other support services.

In a business transactional sense, concluding a business transaction canbe viewed as a sequential process of satisfying a series ofinter-related, but necessary conditions. In a mechanical sense, theprocess of achieving or satisfying the conditionality requirementsrequires a stepwise and simultaneous:

-   -   generation of new data by the system's internal functions; or        the    -   selection and re-configuration of existing data;    -   which is then entered into the system in an appropriate and        logical time sequence to satisfy the necessary contractual        pre-conditions.

Although stated in simplistic terms above, this function requires theintegration of data from multiple data sources, a transformation of someof that data as well as a re-ordering of re-configured untransformeddata with newly generated data outcomes.

A third level of systems logic is now described. The two stagesdescribed above involve data inputting and processing. The results ofthese processes create a new series of values representing variablesinfluencing new equilibrium conditions in the post transaction stages ofthe process.

The new equilibrium conditions are reflected as data outputs which mustbe properly allocated:

-   -   internally of the system    -   externally of the system but internally within a firm's intranet        systems    -   externally to other Internet systems

The timing and sequencing of the data output distribution and allocationprocess is, in turn, influenced by functions described as part of datainterfacing, processing and integration which simultaneously occur, orhave already occurred.

It will be understood that the invention disclosed and defined in thisspecification extends to all alternative combinations of two or more ofthe individual features mentioned or evident from the text or drawings.All of these different combinations constitute various alternativeaspects of the invention.

1. A method of operating a computer to facilitate a commercialtransaction involving a plurality of negotiable trading parameters,including the following steps resulting from the execution of a computerprogram; accepting in respect of a first entity a desired tradingprofile including at least desired values or ranges of multiple of saidtrading parameters and information for establishing one or morefunctional relationships between variations in at least a key tradingparameter and other of said trading parameters; establishing one or moremathematical relationships between variations in at least the keytrading parameter and the other of said trading parameters; wherein saidone or more mathematical relationships can be used to determine a set oftrading profiles having substantially equal expected desirability valuesto said desired trading profile; and determining whether a submittedtrading profile from a second entity has a desirability value thatequals or exceeds the desirability value of said desired trading profileusing said one or more mathematical relationships.
 2. A method accordingto claim 1, wherein said first entity is a seller and said tradingprofile relates to the trading parameters desired by a seller.
 3. Amethod according to claim 1, wherein said trading parameters include oneor more of: price, volume, payment terms, credit terms, credit rates ofinterest, transport charges, logistics charges, insurance charges,inspection charges, finance charges, country adjustments and credit riskadjustments.
 4. A method according to claim 1, wherein said key tradingparameter is price.
 5. A method according to claim 1, wherein the secondentity is a buyer.
 6. A method according to claim 1, wherein when adesirability value of a trading profile of the second entity equals orexceeds said desirability value of said desired trading profile, acommercial transaction is initiated between said first and secondentities based on a transaction trading profile.
 7. A method accordingto claim 6, wherein said submitted trading profile does not have adesirability value that equals or exceeds the desirability value of saiddesired trading profile, said method further including the steps of:accepting information from the second entity for establishing one ormore functional relationships between variations in at least a keytrading parameter and other of said trading parameters for the secondentity; and establishing one or more mathematical relationships betweenvariations in at least the key trading parameter and the other of saidtrading parameters for the second entity; wherein said one or moremathematical relationships can be used to determine a set of tradingprofiles having substantially equal expected desirability values to saidsubmitted trading profile of said second entity; and determining atransaction trading profile using said mathematical relationshipsbetween variations in at least the key trading parameter and the otherof said trading parameters for the second entity, which has adesirability value that equals or exceeds the desirability value of saiddesired trading profile.
 8. A method according to claim 7, wherein saidtransaction trading profile is a trading profile which is closest on aminimum squared distance measure or equivalent measure from saidsubmitted trading profile.
 9. A method according to claim 1, whereinwhen said submitted trading profile or a trading profile having asubstantially equivalent desirability value to said second entity, has adesirability value to said first entity that is less than thedesirability value of said desired trading profile, actions are taken toestablish at least one of a new submitted trading profile and a newdesired profile.
 10. A method according to claim 9, further includingthe step of suggesting one or more changes in at least one of saidsubmitted and desired trading profiles.
 11. A method according to claim10, wherein suggested changes to said submitted trading profile aresuggested to said second entity and suggested changes to said desiredtrading profile are suggested to said first entity.
 12. A methodaccording to claim 11, wherein said suggested changes represent acompromise between at least one trading parameter of said submittedtrading profile and at least one trading parameter of said desiredtrading profile.
 13. A method according to claim 12, wherein saidsuggested changes are determined using a minimum squared distancemeasure or equivalent measure.
 14. A method according to claim 9,wherein at least one of said first and second entities modifies a valueor range of at least one said trading parameter of that entity'srespective submitted trading profile or desired trading profile, and,after modifying said at least one trading profile, further comprisingthe step of determining whether the desirability value of said submittedtrading profile equals or exceeds the desirability value of said desiredtrading profile using said one or more mathematical relationships.
 15. Amethod according to claim 1, wherein the information for establishingone or more functional relationships between variations in at least akey trading parameter and other of said trading parameters includes atleast one additional desired trading profile having an equal orsubstantially equal desirability value to the first desired tradingprofile.
 16. A method according to claim 15, wherein in each of theequal or substantially equal desired trading profiles, the tradingparameter of price is different in each profile.
 17. A method accordingto claim 15, wherein in each of the equal or substantially equal desiredtrading profiles, changes in price are indexed against each of the othertrading parameters.
 18. A method according to claim 15, wherein in eachof the equal or substantially equal desired trading profiles, thesensitivity of the trading parameter of price is quantified against eachof the other trading parameters.
 19. A method according to claim 15,wherein the sensitivity of price against groups of at least two of theother trading parameters is independently quantified.
 20. A methodaccording to claim 1, further including the step of identifying theprospective buyer and the prospective seller by a search based on aproduct and/or service classification code.
 21. A method according toclaim 20, including the steps of providing a product and/or serviceclassification code; providing a database of records relating torespective business entities, said records including information,indexed according to said classification code, recording at least oneproduct or service provided by, or required by, said entity and at leastone desired trading profile in relation to said at least one product orservice; and performing, in response to supplied search informationincluding at least one classification code, and at least one submittedtrading profile, a search of said database for entities having a desiredtrading profile at least compatible with said submitted trading profile.22. A method according to claim 21, wherein the classification code isorganized in an hierarchical manner, so that search information ofvariable specificity or granularity can be provided.
 23. A methodaccording to claim 21, wherein said classification code is, or is basedon or derived from, an internationally recognized product and/or serviceclassification code.
 24. A method according to claim 23, wherein theclassification code is the Harmonized Tariff Code.
 25. A methodaccording to claim 20, wherein the search information includessupplementary information specific to business organizations selectedfrom geographic regions, desired trading terms, and credit profiles. 26.A method according to claim 20, and further including: ranking theresults of the search using one or more predetermined ranking criteria.27. An e-commerce transaction facilitation system, including: a salesmodule; a first enterprise resource planning system of a selling entity;a procurement module; a second enterprise resource planning system of apurchasing entity, and wherein said sales and procurement modules residein a computer system of a single entity, at least one of an operativeconnection between said sales module and said first enterprise planningsystem and an operative connection between said procurement module andsaid second enterprise planning system can be made via a web browser,and said modules can be utilized by at least one entity via a webbrowser, and wherein the computer system includes processing means, afirst associated memory for storing a set of trading parameters and asecond associated memory for storing a series of instructions to causethe sales module to: accept in respect of a first entity a desiredtrading profile including at least desired values or ranges of multipleof said trading parameters and information for establishing one or morefunctional relationships between variations in at least a key tradingparameter and other of said trading parameters; and establish one ormore mathematical relationships between variations in at least the keytrading parameter and the other of said trading parameters; wherein saidone or more mathematical relationships can be used to determine a set oftrading profiles having substantially equal expected desirability valuesto said desired trading profile; and determine whether a submittedtrading profile from a second entity has a desirability value thatequals or exceeds the desirability value of said desired trading profileusing said one or more mathematical relationships.
 28. A systemaccording to claim 27, further including a search/directory module. 29.A system according to claim 27, wherein said sales module includes meansfor maintaining confidential at least some information accepted fromsaid first entity.
 30. A system according to claim 27, wherein saidprocurement module includes means for maintaining confidential at leastsome information accepted from a second entity.
 31. A system accordingto claim 27, wherein said sales module includes means for determining adesirability value of at least one additional desired trading profilefrom a plurality of desired trading profiles accepted from said firstentity.
 32. A system according to claim 27, wherein said procurementmodule includes means for determining a desirability of at least oneadditional submitted trading profile from a plurality of submittedtrading profiles accepted from said second entity.
 33. A systemaccording to claim 27, further including means for conducting anauction.
 34. A system according to claim 27, including means forindicating the submitted profile with the highest desirability value.